build(ios): enable iOS bazel targets on Bazel 9 and mac CI#1164
Merged
Conversation
rules_apple 4.5.3 / apple_support 2.7.0 (upgraded in #1163) support Bazel 9 (rules_apple#2863 was fixed by rules_apple#2868 and apple_support#497), so the Bazel 8 workarounds can go: - drop tags = ["manual"] and the stale Bazel 9 comments from the wordchains_ios targets; target_compatible_with already keeps them off Linux runs, and diff-build passes --skip_incompatible_explicit_targets - remove the USE_BAZEL_VERSION=8.2.1 pin from release-wordchains-ios - build the iOS app and run ios_unit_test with bazel in the test-ios macOS job, behind the existing wordchains path filter Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Jw99o89a2UYe9NKLE9zGUx
Deploying with
|
| Status | Name | Latest Commit | Preview URL | Updated (UTC) |
|---|---|---|---|---|
| ✅ Deployment successful! View logs |
1d4-web | 4223590 | Commit Preview URL Branch Preview URL |
Jul 04 2026, 06:48 PM |
Under Bazel 9 the Apple rules transition to real target platforms (ios_sim_arm64, whose OS constraint is os:ios), so os:macos marked the ios_application incompatible with its own platform: target platform (@@apple_support+//platforms:ios_sim_arm64) didn't satisfy constraint @@platforms//os:osx The constraint only existed to keep Linux CI off these targets, and os:ios still does that (linux doesn't satisfy it) while matching the iOS transition. Bazel 8 didn't use real platforms for Apple builds, which is why os:macos used to pass. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Jw99o89a2UYe9NKLE9zGUx
The Apple bundling rules (ios_application, ios_unit_test) transition to
an iOS target platform before target_compatible_with is evaluated, so
os:ios is satisfied on Linux too and diff-build's
--skip_incompatible_explicit_targets never kicks in — analysis fails
resolving @bazel_tools//tools/cpp:toolchain_type for iOS instead:
No matching toolchains found for types:
@@bazel_tools//tools/cpp:toolchain_type
Restore tags = ["manual"] on those two targets (diff-build queries
exclude manual) with a comment explaining the real reason. The mac
test-ios job and the release workflow request them by explicit label,
which builds manual targets. The plain swift_library targets don't
transition, so os:ios correctly skips them on Linux.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jw99o89a2UYe9NKLE9zGUx
ios_application transitions its own top-level platform to iOS, but ios_unit_test stays in the host configuration and only transitions its deps, so os:ios made it incompatible on the mac runner: target platform (@@platforms//host:host) didn't satisfy constraint @@platforms//os:ios The app build step passed on Bazel 9; this unblocks the test step. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Jw99o89a2UYe9NKLE9zGUx
The repo builds with --compilation_mode=opt, where rules_swift disables -enable-testing by default (it is only on for dbg/fastbuild), so the @testable import in WordGraphTests failed with "module 'WordChains' was not compiled for testing". SwiftPM's swift test builds debug, which is why the existing test step never hit this. Pass --features=swift.enable_testing on the CI test invocation only, leaving the app and release builds without testability. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Jw99o89a2UYe9NKLE9zGUx
The test bundle now builds and runs, but the default test runner created a "New-iPhone 6s Plus-26.5" simulator - an iPhone 6s Plus paired with the latest iOS 26.5 runtime, which that device type cannot run - and the tests exited with 15 before executing. Pass --ios_simulator_device="iPhone 16" so a valid device/runtime pair is used. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Jw99o89a2UYe9NKLE9zGUx
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Follow-up to #1163. rules_apple 4.5.3 / apple_support 2.7.0 support Bazel 9 (rules_apple#2863 was fixed by rules_apple#2868 + apple_support#497; the 4.5.3 BCR presubmit tests Bazel 9.x), so the Bazel 8 workarounds can be removed and the iOS targets can run in CI:
wordchains_ios/BUILD.bazel: droptags = ["manual"]and the stale "rules_apple doesn't support Bazel 9" comments from all four targets.target_compatible_with = ["@platforms//os:macos"]still keeps them out of Linux runs (wildcards skip incompatible targets;diff-buildalready passes--skip_incompatible_explicit_targets).release-wordchains-ios.yml: remove theUSE_BAZEL_VERSION: 8.2.1pin — the release build now uses the repo's Bazel 9.1.0.branch.yml/test-ios: after the existing SwiftPMswift test, build//domains/games/apps/wordchains_ios:WordChainsand run:WordChainsTestswith bazel on the macOS runner, behind the existing wordchains path filter (which this PR itself triggers, so the new steps are exercised here).Notes
word_graph_jsondata dep); thetest-iosdisk/repository caches should make later runs cheap.ios_unit_testneeds an iOS simulator runtime on the runner; if that proves flaky we can keep the app build and drop the sim test.🤖 Generated with Claude Code
https://claude.ai/code/session_01Jw99o89a2UYe9NKLE9zGUx
Generated by Claude Code